GoogleのEddystoneとはなんなのか

大村貴俊

2015.07.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

GoogleからEddystoneなる発表がありました

米Googleから、2015年7月14日に、Eddystoneが発表されました。これは、Bluetooth Low Energy(BLE)を用いたビーコン向けの規格で、競合としてはApple社のiBeaconがあります。 iBeaconの競合だからと、2年前のエイプリルフールでふざけた規格を発表した私に、少し調査をしろという伝令が廻ってきたとか廻ってきてないとか、そんな状況なので少し調べた内容をまとめます。

EddystoneとiBeaconの違い

EddystoneがiBeaconと外枠で大きく違う点が2つほどあります。それは

iBeaconと違いオープン(Apache v2.0ライセンス)である
AndroidやiOSなど、BLEをサポートしているマルチプラットフォームで利用できる

iBeaconは良い意味でも悪い意味でも、iOSに仕様をブラックボックス化されており、iOS7以上で気軽に実装が出来てが非常に楽でした。その反面、やりたいことをダイレクトに行えているのかがわからない（おそらく端末ごとのBLEパラメータの調整をOSレベルでしてるはず）という欠点もありました。 EddystoneはGitHubにてソースコードがまるごと公開されており、その気になれば色々細部に調整や拡張できそうな気がします。トラブルが起きた際も追いかけやすい利点があります。

また、iOSはApple社が主導で動いていましたが、EddystoneはGoogle社が動いており、AndroidやiOSなどのクロスプラットフォームで利用できるのがウリです。 iBeaconもAndroidで利用できますが、Alt Beaconなどのライブラリを手配したりと、弊社小室が孤軍奮闘していた記録が沢山残っています。

そもそもBLE Beaconとはなんなのだろうか

通常のBluetooth機器はマスター(親)とスレーブ(子)をペアリングして利用します。身近なところでパソコンとキーボード・マウスや音楽プレーヤーとヘッドホンなど、親となるパソコン・音楽プレーヤーと異なるキーボードとマウスを、ヘッドホンをペアリングして利用しています。このペアリングする動作の時に、周辺機器をスキャンする動作が発生するのですが、機器のリンクをするのに識別情報を送信する必要があります。 Bluetoothで通信を行うための0〜39チャンネルのうち、37〜39チャンネルをアドバタイジングチャンネルと呼び、スレーブからアドバタイジングパケットを送出します。それを、マスターでスキャンして、ペアリングします。(この場合、マスターをスキャナとかイニシエータとか、スレーブをアドバタイザとか呼びますがそこまで重要ではない単語です)

BLE Beaconは、このアドバタイジングチャンネル内で、アドバタイジングパケットを利用しています。そのため、ペアリングという概念がありません。その代わり、チャンネルを専有することがなく、一定間隔で送信され、無線LAN等の2.4GHz帯を使用する通信と混線することが少ないという利点があります。アドバタイジングパケットの中で、Beacon用にフォーマットを決めたのが、iBeaconやEddystoneとなります。

送出フレームタイプ

現在Eddystoneで公開されている送出フレームタイプが3パターンあります。 iBeaconでは1パターンのみでした。ここではそれぞれのフレームタイプがどんなものかを説明します。

iBeaconのフレームタイプ

iBeaconで慣れ親しんだUUID/Major/Minor/Measured Powerを送るフレームタイプです。

Byte offset	Field	Description
0-1	Identifier	Apple Conpany Identifier:0x004C
2	Data Type	iBeacon:0x02
3	Data Length	0x15 (21byte)
4-19	UUID	固定ID
20-21	Major	0-65535で好きな数字を設定
22-23	Minor	0-65535で好きな数字を設定
24	Measured Power	Measured Power at 1 m

詳しい内容等はiBeacon系の資料を調べていただければいいと思いますが、実際のデータ部分は4バイト目からの21バイトが固定長です。

Eddystone1 Eddystone-UID

iBeaconに最も近いフレームです。UUIDの代わりとなります。

Byte offset	Field	Description
0	Frame Type	0x00(UID)
1	TX Power	Calibrated Tx Power at 0 m
2-11	Namespace ID	名前ID
12-17	Instance ID	インスタンスID
18-19	RFU	Reserved for future:0x00

Namespace IDが、iBeaconでのUUIDに該当する箇所に当たります。 Eddystoneでは、ドメイン名をSHA-1ハッシュ化した最初の10バイトを使用することを推奨しています。弊社のClassmethodの場合は、「7C C6 68 68 AA 38 5F F7 6F 46」となります。もしくは、iBeaconのUUID(version 4 UUID)の、5バイト目から6バイト分削除したものの利用を併せて推奨しています。（iBeaconのUUIDは16バイト） Instance IDはiBeaconのMajor/Minorと同様の使用方法です。

端末を特定したネイティブアプリでの動作を想定しています。

Eddystone2 Eddystone-URL

UrlBeaconの概念を取り入れた仕組みです。 Eddystone端末からURLの入ったフレームを送出します。

Byte offset

Field

Description

Frame Type

0x10(URL)

TX Power

Calibrated Tx Power at 0 m

URL Scheme

URLのスキーマを指定できる。以下のフォーマット

Hex	Expansion
0x00	http://www.
0x01	https://www.
0x02	http://
0x03	https://

Encoded URL

上記URLスキーマーを除いたURL。最大17バイト。

2014年10月にGoogle社が発表した新プロジェクトで、「Physical Web」という規格があり、今回のEddystone-URLがまさにその実装と言った形です。特定のアプリに依らない、IoT機器との連動やブラウザだけで簡単に動作する、オープンなものを目指したものです。ただし、送出できるパケット数は最大でも17バイトと決まっており、基本的にURL短縮サービスの利用を前提としています。

（Eddystone-URLの利用想定図引用元：Google Developers Blog）

Eddystone3 Eddystone-TLM

Eddystoneの状態を送出するフレームになります。

Byte offset	Field	Description
0	Frame Type	0x20(TLM)
1	Version	TLMバージョン:0x00
2-3	VBATT	バッテリー残量 1mV/bit
4-5	TEMP	温度
6-9	ADV_CNT	起動、もしくは再起動してからのアドバタイジングパケット送出回数
10-13	SEC_CNT	起動、もしくは再起動してからの経過時間

バッテリーの状態や温度といったアラートをスキャナ側で把握することができる仕組みになっています。

最後に

iBeaconでちょっと欲しかった機能を拡張した形となったEddystoneですが、なによりURLの送出ができるようになったのが大きいです。今まではネイティブアプリが必要であったものが、今後はアプリがなくてもChrome BrowserなどでURLを開くといったことができるようになります。例えば、運行中のバスの情報を知りたい時、バス停に近づいただけで今の運行情報が確認できたり。例えば、映画のポスターにEddystone-URL送出Beaconを設置して、その映画のトレーラー動画に直接リンクしたり、とか。今後の使い方次第では夢が広がる気がします。次のエントリーでは、実際にこれらのフレームを利用してAPIによるサンプルを動かしてみようと思います。